Windows Server 2008 : Configuring Wireless Access

Wireless networking hardware requires the use of technology that deals with radio frequencies as well as data transmission. The most widely used standard is 802.11 produced by the IEEE. This is a standard defining all aspects of radio frequency wireless networking. There have been several amendments to the 802.11 standard, the most recent being 802.11i.

Many Wireless networks use an AP to gain connectivity. In this type of network, the AP acts like a hub, providing connectivity for the wireless computers. It can connect the wireless LAN to a wired LAN, allowing wireless computer access to LAN resources. This includes such resources as file servers or existing internet connectivity. This type of wireless network is said to run in infrastructure mode.

An ad hoc or peer-to-peer wireless network is one in which a number of computers each equipped with a wireless networking interface card, can connect without the use of an AP. Each computer communicates with all of the other wireless-enabled computers directly. This allows for the sharing of files and printer services, but may not be able to access wired LAN resources. The exception to this is if one of the computers acts as a bridge or AP to the wired LAN using special software.

As you might be familiar with in Windows Server 2003, Wireless Auto Configuration will attempt to pair up configured preferred wireless networks with the wireless networks that are broadcasting their network name. If no such available networks exist that match a preferred wireless network, Wireless Auto Configuration will then send a number of probe requests to attempt to find a match. These are to try and determine if the preferred networks in the ordered list are non-broadcast networks. The end result of this total process should be that broadcast networks are connected to before non-broadcast networks. This even includes situations where a non-broadcast network is higher in the preferred list than a broadcast network. A big downside of this method, however, is that a Windows XP or Windows Server 2003 wireless client has to advertise its list of preferred wireless networks when sending probe requests. This leaves clients vulnerable while sending these probe requests.

Windows Server 2008 presents a better option. By configuring the wireless networks as broadcast, the wireless network names will be included in the Beacon frames sent by the wireless AP. If you set the wireless network as non-broadcast, the Beacon frame contains a wireless network name. This name is set to NULL, which results in Wireless Auto Configuration attempting connection to the wireless networks in the preferred network list order. This is regardless of whether they are broadcast or non-broadcast. By explicitly marking wireless networks as broadcast or non-broadcast, Windows Server 2008 wireless clients only send probe requests for non-broadcast wireless networks. This reduces wireless client side vulnerability and enhances security.

Previously, if a preferred wireless network could not be connected to and the wireless client was configured in a way that prevented automatic connections not in the preferred list by default, then Wireless Auto Configuration would create a random wireless network name. Then it would place the wireless network adapter in infrastructure mode. The random wireless network does not have a security configuration, making it possible for all kinds of malicious users to connect to the wireless client, thereby using the random wireless network name.

For computers running Windows Server 2008 that use updated wireless drivers designed for Windows Vista, Wireless Auto Configuration will remove this vulnerability by parking the wireless network adapter in a passive listening mode. A parked wireless device does not send probe request frames for a random wireless network name. It also does not allow for any other names, so malicious users cannot connect to the wireless client.

If you are using a wireless network adapter driver that was designed for Windows XP, computers running Windows Vista or Windows Server 2008 will use the behavior of the Wireless Client Update for Windows XP with Service Pack 2 (a random wireless network name with a security configuration).

Windows Server 2008 troubleshooting wireless connections is made much easier through the following features:

• Network Diagnostics Framework The Network Diagnostics Framework is an extensible architecture that provides users with a means to recover from and troubleshoot problems with network connections. In the case of a failed wireless connection, Network Diagnostics Framework will give the user the option to identify and correct the problem. Wireless support for the Network Diagnostics Framework tries to discover the source of the failed connection and will automatically fix the problem. Also based on your security considerations, it can be made to prompt the user to make the appropriate configuration change themselves.

• For a failed wireless connection attempt, the wireless components of Windows Server 2008 now records detailed information about the connection attempt in the Windows event log. Support professionals can now access and use these records to perform troubleshooting tasks, and attempt to resolve the problem quickly if the wireless diagnostics either could not resolve the problem or when it could resolve the problem, but the problem cannot be fixed by changing wireless client settings. This will cut down on the time needed to resolve wireless connection support problems. These can also be automatically collected by network administrators using Microsoft Operations Manager, to be analyzed for patterns and wireless infrastructure design changes.

• You can now gain access to in-depth information about the computer’s state and wireless components in Windows, and their interaction when the problem occurred. This can be done using information from wireless diagnostics tracing in Windows Server 2008. To use wireless diagnostics tracing, you must start tracing, reproduce the problem, stop tracing, and then collect the tracing report. To view the tracing report, in the console tree of the Reliability and Performance Monitor snap-in open Reports | System | Wireless Diagnostics.

Windows Server 2003 and Windows XP do not have a command-line interface that allows you to configure the wireless settings that are available from the wireless dialog boxes in the Network Connections folder, or through the Wireless Network (IEEE 802.11) Policies Group Policy settings. Command-line configuration of wireless settings can help deployment of wireless networks in the following situations:

• Automated script support for wireless settings without using Group Policy Wireless Network (IEEE 802.11) Policies Group Policy settings only apply in an Active Directory domain. For an environment without Active Directory or a Group Policy infrastructure, a script that automates the configuration of wireless connections can be run either manually or automatically, such as part of the login script.

• Bootstrapping of a wireless client onto the protected organization’s wireless network. A wireless client computer that is not a member of the domain cannot connect to the organization’s protected wireless network. Furthermore, computers are not able to join the domain until a successful connection has occurred to the organization’s secure wireless network. A command-line script provides a method to connect to the organization’s secure wireless network to join the domain.

In Windows Server 2008, you can use Netsh commands in the netsh wlan context to do the following:

• Save all wireless client settings in a named profile including general settings (the types of wireless networks to access), 802.11 settings (SSID, type of authentication, type of data encryption), and 802.1X authentication settings (EAP types and their configuration).

• Specify the list of allowed and denied wireless network names.

• Specify the order of preferred wireless networks.

• Display a wireless client’s configuration.

• Remove the wireless configuration from a wireless client.

• Migrate a wireless configuration setting between wireless clients.

Many applications are not network aware, resulting in customer confusion and developer overhead. For example, an application cannot automatically adjust its behavior based on the currently attached network and conditions. Users might have to reconfigure application settings depending on the network to which they are attached (their employer’s private network, the user’s home network, the Internet). To remove the configuration burden, application developers can use low-level Windows APIs, data constructs, and perhaps even probing the network themselves to determine the current network and adjust their application’s behavior accordingly.

To provide an operating system infrastructure to allow application developers to more easily reconfigure application behavior based on the currently attached network, the Network Awareness APIs in Windows Server 2008 make network information available to applications and enables them to easily and effectively adapt to these changing environments. The Network Awareness APIs allow applications to obtain up-to-date network information and location change notification.

Let’s take a look at how to deal with the variety of elements available with Windows Server 2008 in regards to wireless network access and how they will be applied to your exam.

Set Service Identifier (SSID)

The Service Set Identifier (SSID) is a 32-character unique identifier attached to the header of packets that are sent over a Wireless Local Area Network (WLAN). The SSID acts as a password when a mobile device tries to connect to the BSS. The SSID differentiates one WLAN from another. This way all APs and all devices attempting to connect to a specific WLAN must use the same SSID in order to succeed. No device will be permitted to join the BSS unless it can provide the unique SSID. SSID is not a security measure, because it can very easily be sniffed due to being stored in plain text.

In Windows Server 2008, an additional wireless network configuration setting has been added that can indicate whether a wireless network is broadcast or non-broadcast. This setting can be configured locally through the “Manually connect to a wireless network” dialog box, the properties of the wireless network, or through Group Policy. The “Connect even if the network is not broadcasting” check box determines whether the wireless network broadcasts or does not broadcast its SSID. Once selected, Wireless Auto Configuration sends probe requests to discover if the non-broadcast network is in range.

Configured wireless networks are now openly marked as broadcast or non-broadcast. Windows Server 2008-based wireless clients only send probe requests for wireless networks that are configured for automatic connection and as non-broadcast.

This method allows Windows Server 2008-based wireless clients to detect non-broadcast networks when they are in range. Therefore, even though they are not broadcasting the name of their wireless network, they will appear in the list of available wireless networks when they are in range. The wireless client detects whether the automatically connected, non-broadcast networks are in range based on the probe request responses. Then Wireless Auto Configuration attempts to connect to the wireless network in the preferred networks list order. This is regardless of whether they are configured as broadcast or non-broadcast. By only sending probe requests for automatically connected, non-broadcast networks, Windows Server 2008-based wireless clients reduce the number of situations in which they disclose their wireless network configuration.

You can also configure manually connected, non-broadcast wireless networks. In doing so, you can control exactly when to send probe requests. Manually connected, non-broadcast wireless networks are always displayed in the list of available networks, allowing users to initiate connections as needed.

Despite the improvements in non-broadcast network support in Windows Server 2008, Microsoft recommends against using non-broadcast wireless networks.

Wi-Fi Protected Access (WPA)

Wi-Fi Protected Access (WPA) was designed to provide a much higher level of security for wireless users than existing WEP standards provide. The WPA specification makes allowances both for network-based authentication for corporate networks, and for a special home mode for use in a SOHO or home-user environment. WPA is capable of interoperating with WEP devices, although in cases of interoperability, the default security for the entire wireless infrastructure reverts to the WEP standard. WPA’s network-based authentication can make use of existing authentication technologies such as RADIUS servers, so adding the secure technology that WPA represents won’t disrupt existing network infrastructures too much. Windows Server 2008 offers full support and configuration for WPA through the Wireless Group Policy settings.

Wi-Fi Protected Access 2 (WPA2)

Windows Server 2008 includes built-in support to configure WPA2 authentication options with both the standard profile (locally configured preferred wireless networks), and the domain profile with Group Policy settings. WPA2 is a product certification available through the Wi-Fi Alliance that certifies wireless equipment as being compatible with the IEEE 802.11i standard. WPA2 in Windows Server 2008 supports both WPA2-Enterprise (IEEE 802.1X authentication) and WPA2-Personal (pre-shared key authentication) modes of operation.

Windows Server 2008 also includes full support for WPA2 for an ad hoc mode wireless network including the Fast Roaming settings. Fast roaming is an advanced capability of WPA2 wireless networks that allow wireless clients to more quickly roam from one wireless AP to another by using pre-authentication and pair wise master key (PMK) caching in infrastructure mode. With Windows Server 2008, you can configure this feature using the Wireless Group Policy settings.

Ad Hoc vs. Infrastructure Mode

To set up an ad hoc wireless network, each wireless adapter must be configured for ad hoc mode versus the alternative infrastructure mode. In addition, all wireless adapters on the ad hoc network must use the same SSID and the same channel number.

An ad hoc network tends to feature a small group of devices all in very close proximity to each other.

Performance suffers as the number of devices grows, and a large ad hoc network quickly becomes difficult to manage. Ad hoc networks cannot bridge to wired LANs or to the Internet without installing a special-purpose gateway.

Ad hoc networks make sense when needing to build a small, all-wireless LAN quickly and spend the minimum amount of money on equipment. Ad hoc networks also work well as a temporary fallback mechanism if normally available infrastructure mode gear (APs or routers) stop functioning.

Most installed wireless LANs today utilize infrastructure mode that requires the use of one or more APs. With this configuration, the AP provides an interface to a distribution system (e.g., Ethernet), which enables wireless users to utilize corporate servers and Internet applications.

As an optional feature, however, the 802.11 standard specifies ad-hoc mode, which allows the radio network interface card (NIC) to operate in what the standard refers to as an independent basic service set (IBSS) network configuration. With an IBSS, APs are not required. User devices communicate directly with each other in a peer-to-peer manner.

Ad hoc mode allows users to form a wireless LAN with no assistance or preparation. This allows clients to share documents such as presentation charts and spreadsheets by switching their NICs to ad hoc mode to form a small wireless LAN within their meeting room. Through ad hoc mode, you can easily transfer the file from one laptop to another. With any of these applications, there’s no need to install an AP and run cables.

The ad hoc form of communications is especially useful in public-safety and search-and-rescue applications. Medical teams require fast, effective communications when attempting to find victims. They can’t afford the time to run cabling and install networking hardware.

Before making the decision to use ad hoc mode, you should consider the following:

• Cost Efficiency Without the need to purchase or install an AP, you’ll save a considerable amount of money when deploying ad hoc wireless LANs.

• Rapid Setup Time Ad hoc mode only requires the installation of radio NICs in the user devices. As a result, the time to set up the wireless LAN is much less than installing an infrastructure wireless LAN.

• Better Performance Possible The question of performance with ad hoc mode is very debatable. Performance can be higher with ad hoc mode because there is no need for packets to travel through an AP. This only applies to a small number of users, however. If you have many users, then you will have better performance by using multiple APs to separate users onto non-overlapping channels. This will help to reduce medium access contention and collisions. Also, because of a need for sleeping stations to wake up during each beacon interval, performance can be lower with ad hoc mode due to additional packet transmissions if you implement power management.

• Limited Network Access There is no distribution system with ad hoc wireless LANs. Because of this, users have limited effective access to the Internet and other wired network services. Ad hoc is not a good solution for larger enterprise wireless LANs where there’s a strong need to access applications and servers on a wired network.

• Difficult Network Management Network management can become a nightmare with ad hoc networks, because of the fluidity of the network topology and lack of centralized devices. The lack of an AP makes it difficult for network managers to monitor performance, perform security audits, and manage their network. Effective network management with ad hoc wireless LANs requires network management at the user device level. This requires a significant amount of overhead packet transmission over the wireless LAN. This again disqualifies ad hoc mode away from larger, enterprise wireless LAN applications.

Infrastructure mode requires a wireless AP for wireless networking. To join the WLAN, the AP and all wireless clients must be configured to use the same SSID. The AP is then cabled to the wired network to allow wireless clients access to, for example, Internet connections or printers. Additional APs can be added to the WLAN to increase the reach of the infrastructure and support any number of wireless clients.

Compared to the alternative, ad hoc wireless networks, infrastructure mode networks offer the advantage of scalability, centralized security management, and improved reach.

The disadvantage of infrastructure wireless networks is simply the additional cost to purchase AP hardware.

Wireless Group Policy

New technology makes it easier for mobile workers to connect to hotspots or corporate LANS, by eliminating the need for manual configuration of the network connection. Enterprises can better manage guest access on their network and provide payment plans such as pay-per-use or monthly Internet access to customers, but in order to do so a strict wireless group, policy must be maintained to better control access.

Wireless network settings can be configured locally by users on client computers, or centrally. To enhance the deployment and administration of wireless networks, you need to take advantage of Group Policy. In doing so, you can create, modify, and assign wireless network policies for Active Directory clients and members of the wireless network. When you use Group Policy to define wireless network policies, you can configure wireless network connection settings, enable IEEE 802.1X authentication for wireless network connections, and specify the preferred wireless networks that clients can connect to. By default, there are no Wireless Network (IEEE 802.11) policies.

Exercise : Creating a New Policy

To create a new policy: